Topics

Why Iterate?

Traditionally, projects have been organized to go through each workflow in sequence, once and only once. This leads to the waterfall lifecycle:

This often results in an integration 'pile-up' late in implementation when, for the first time, the product is built and testing begins. Problems which have remained hidden throughout Analysis, Design and Implementation come boiling to the surface, and the project grinds to a halt as a lengthy bug-fix cycle begins.

A more flexible (and less risky) way to proceed is to go several times through the various development workflows, building a better understanding of the requirements, engineering a robust architecture, ramping up the development organization, and eventually delivering a series of implementations that are gradually more complete. This is called an iterative lifecycle. Each pass through the sequence of process workflows is called an iteration.

Thus, from a development perspective the software lifecycle is a succession of iterations, through which the software develops incrementally. Each iteration concludes with the release of an executable product. This product may be a subset of the complete vision, but useful from some engineering or user perspective. Each release is accompanied by supporting artifacts: release description, user documentation, plans, and so on, and updated models of the system.

The main consequence of this iterative approach is that the sets of artifacts, described earlier, grow and mature over time, as shown in the following diagram.

Information set evolution over the development phases.

What is an Iteration? To top of page

An iteration encompasses the development activities that lead to a product release - a stable, executable versions of product, together with any other peripheral elements necessary to use this release. So a development iteration is in some sense one complete pass through all the workflows: requirements workflow, analysis & design workflow, implementation workflow, test workflow, at least. It is like a small waterfall project in itself.

Release

A release can be internal or external. An internal release is used only by the development organization, as part of a milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to end users. A release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured only from an engineering perspective. Releases act as a forcing function that drives the development team to get closure at regular intervals, avoiding the "90% done, 90% remaining" syndrome.

Iterations and releases allow a better usage over time of the various specialties in the team: designers, testers, writers, etc. Regular releases let you break down the integration and test issues and spread them across the development cycle. These issues have often been the downfall of large projects because all problems were discovered at once during the single massive integration step, which occurred very late in the cycle, and where a single problem halts the whole team.

At each iteration, artifacts are updated. It is said that this is a bit like "growing" software. Instead of developing artifacts one after another, in a pipeline fashion, they are evolving across the cycle, although at different rates.

Minor milestone

Each iteration is concluded by a minor milestone, where the result of the iteration is assessed relative to the objective success criteria of that particular iteration.

Iteration and PhasesTo top of page

Each iteration within a phase results in an executable release of the system.

Each phase in the Rational Unified Process can be further broken down into iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system.

Iteration pattern: Incremental Lifecycle To top of page

"The incremental strategy determines user needs, and defines the system requirements, and then performs the rest of the development in a sequence of builds. The first build incorporates parts of the planned capabilities, the next build adds more capabilities, and so on until the system is complete." [DOD94]

The following iterations are characteristic:

  • a short Inception iteration to establish scope and vision, and to define the business case
  • a single Elaboration iteration, during which requirements are defined, and the architecture established
  • several Construction iterations during which the use cases are realized and the architecture fleshed-out
  • several Transition iterations to migrate the product into the user community

This strategy is appropriate when:

  • The problem domain is familiar
  • Risks are well-understood
  • The project team is experienced

Iteration pattern: Evolutionary Lifecycle To top of page

"The evolutionary strategy differs from the incremental in acknowledging that user needs are not fully understood, and all requirements cannot be defined up front, they are refined in each successive build." [DOD94]

The following iterations are characteristic:

  • a short Inception iteration to establish scope and vision, and to define the business case
  • several Elaboration iterations, during which requirements are refined at each iteration
  • a single Construction iteration, during which the use cases are realized and the architecture fleshed-out
  • several Transition iterations to migrate the product into the user community

This strategy is appropriate when:

  • The problem domain is new or unfamiliar
  • The team is inexperienced

Iteration pattern: Incremental Delivery Lifecycle To top of page

Some authors have also phased deliveries of incremental functionality to the customer [GIL88]. This may be required where there are tight time-to-market pressures, where delivery of certain key features early can yield significant business benefits.

In terms of the phase-iteration approach, the transition phase begins early on and has the most iterations. This strategy requires a very stable architecture, which is hard to achieve in an initial development cycle, for an "unprecedented" system.

The following iterations are characteristic:

  • a short Inception iteration to establish scope and vision, and to define the business case
  • a single Elaboration iteration, during which a stable architecture is baselined
  • a single Construction iteration, during which the use cases are realized and the architecture fleshed-out
  • several Transition iterations to migrate the product into the user community

This strategy is appropriate when:

  • The problem domain is familiar
    • the architecture and requirements can be stabilized early in the development cycle
    • there is a low degree of novelty in the problem
  • The team is experienced
  • Incremental releases of functionality have high value to the customer

Iteration pattern: "Grand Design" Lifecycle To top of page

The traditional waterfall approach can be seen as a degenerated case in which there is only one iteration in the construction phase. It is called "grand design" in [DOD94]. In practice, it is hard to avoid additional iterations in the transition phase.

The following iterations are characteristic:

  • a short Inception iteration to establish scope and vision, and to define the business case
  • a single very long Construction iteration, during which the use cases are realized and the architecture fleshed-out
  • several Transition iterations to migrate the product into the user community

This strategy is appropriate when:

  • a small increment of well-defined functionality is being added to a very stable product
  • the new functionality is well-defined and well-understood
  • The team is experienced, both in the problem domain and with the existing product

Iteration pattern: Hybrid Strategies To top of page

In practice few projects strictly follow one strategy. You often end up with a hybrid, some evolution at the beginning, some incremental building, and multiple deliveries. Among the advantages of the phase-iteration model is that it lets you accommodate a hybrid approach, simply by increasing the length and number of iterations in particular phases:

  • For complex or unfamiliar problem domains, where there is a high degree of exploration: increase the number of iterations in the elaboration phase and its length.
  • For more complex development problems, where there is complexity translating the design into code: increase the number of iterations in the construction phase and its length.
  • To deliver software in a series of incremental releases: increase the number of iterations in the transition phase and its length.
 

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process